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ABSTRACT 


This thesis presents a design and partial inplemertation 
cf a program family cf extended pretty printers. Factors 
that influence the readability (perception) and understand- 
ability (cogniticn) of computer programs are indentified, 
previous work is reviewed, and new solutions are suggested. 


Extensicns to the prévious pretty printer designs includs 


sv 


capability to selectively display levels of control of 43 
program. in order | <6 accommodate different computer 
languages and to allicw for several secondary functions, a 
meme y Of pretty printers is designed. This design facili- 
tates easy extension, contraction and modification. 
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I. INTRODUCTION 
Programs are written to be read and understcod by 
people. The textual representation should be such that it 
is easy to read. That is, the representation cf the pregran 
should be such that it reduces the visual burden on the user 
and allows him to develop and exploit visual clues to aid in 
Beading. In additicn, the text of the program should be 
designed so that it is ¢asy for the reader to grasf the 
meaning cf the program: that is, the representation of the 
program should help the reader understand th progran. 

Fitteen years aqe Dijkstra argued chat ™... our intel- 
Jectual powers are rather geared to master static relations 
and cur powers to visualize processes evolving in time are 
relatively poorly developed. For that reason we should do 
(as wise programmers aware of our limitations) our utmost to 
shorten the conceptual gap between <th2 static program and 
the dynamic process, to make the correspondence between the 
program (spread out in tex+ spacs) and «he process (spread 
Sie) in ~<ime) aS trivial as possible." {Ref. 16]. There is 
an additional conceptual gap between the program spread our 
in <t¢xt and how we represen* and manipulate the static 
program and its dynamic process in our minds. Here also we 
emould try to narzow the conceptual gap so that the prcgran 
is easy te read and tc understand. 

In the computer science literature, readability and 
understandability aze often used interchangably. Readability 
Meectelaced to physical conditions, for instance, the size, 
sype font, color, and clarity of characters, proper indenta- 
tions, and the spacing between lines. Understandability is 
Bemacted tc psychological conditions, for instance, pattern, 


memory, logic, and repetition learnings. Precisely speaking, 
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readability means good perception and understandabilty means 
good ccgnition. The system that will be designed in this 
thesis will seek to improve both readability and understand- 
ability by means of reformatting computer programs and 
presenting the user with alternative representations te aid 
understanding. 

There is evidence to show that readability and under- 
standability of computer programs is an important issue that 
2s directly related to programmer productivity. Although 
this has been recognized for some time, further improvements 
in the textual representation of computer programs are 
vossikl¢e. This thesis will review the previous work, analyze 


the remaining preblems, and prorose new solutions. 
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A. BACKGROUND 


ened cLudy GC: Commerical programming practices, Elshoff 
(Ref. 5j found that mest programs were poorly written. They 
were very large, extremely difficult +o read and undezstand, 
and mcre ccmplex than necessary. Furthermore, the study 
determined that programming language usage was poor and 
ancorsistent. The results of the survey by Lientz [Ref. 6] 
Show that the quality of programming is a enearally 
perceived problem. There has been a major effort to improve 
programming practices. But there still exist many programs 
*hat are difficult te read and understand and y2t they must 
regularly be corrected and/or modified. 

There are many factors connected with the readability 
and understandability of a computer progran. The reader's 
familiarity with the progran, knowledge of the application 
azrea, and cwn programming style are important factors thax 
are mcstly independent of the program {RBef. 4}. This «thesis 
is concentrated cn the representation of program *ext that 
impacts its readability and understandabili«v. A readak 
vrogram always seems to exhibit a common set cf proper 
fRef. 8} (Ref. 9) [Ref. 10]. The program is well commente 
mie) Lodzcai structure of the program is constructed fron 


ct 


as 


common set of single-ertry single-exit flow of contro 
ULtsS. Variable names are? mnemonic and references to then 
localized. The rrogram's physicai layout makes the salient 
features of the algorithm + 
(Ref. 14}. 


that is implemented stand out 
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Since abstraction is an important mechanism that people 
use to understand prcegrams, the suppression of details ina 
program can aid understanding. Modern design methcdolcgies 
include tcp down design using stepwise refinement. In this 
methodology, the programmer designs successive leveis of the 
program. These levels are visible during the design but are 
often not visible in the final progran. The undéerstand- 
ability cf a program can b2 improved by making the lavels of 
the program structure visible. Tt 13 trues that a program 
may have all these properties and still be unzeadable and 
not understandabie; however, the readability and under- 

tandability of a pregram are cartain to suffer when it 


lacks one or more of the the properties {Ref. 14]. 


Be. DEFINITION 


Rubin [Ref. 14] defined a pretty printer as follows: 
iat. «iS a software tool to format programs to make then 
éasier tc read and understand." The extended pretty printer 
can te defined as: a software tool to improve readability 
and understandability by aiding level documentation, 
commenting and reformatting. These additional extansions to 
pretty printers wili aid people in understanding the prcgram 
by making more visible the structure of the program and 
supporting the viewing of the levels of the program. The 
Primary function of an extended pretty orinter is te add 
some level documentation and comments, to insert spaces and 
linefeeds between tokens - character strings - and to decide 
where and hcw to break lines that are too long to fit on the 


output medium. 
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C. GCALS 


The methods for improving the readability and under- 
Peamadability of a program use a set of specific transfcrma- 
tions that can be applied to the program text. The 
follcwing pregram tranformations can be done Dy an extended 


pretty printer. 


The consistent formating of programs is very impor- 
meant. Elshoff (Ref. 14] said "Just as paragraphindg and 
Secticning help written Be Ques Siiy so can indentatica, 
keyword positioning, and lcegical grouping aid a programming 
language.". Those jobs can be done automatically ty a 
pretty printer. It will allow the program to be read more 


easily. 


ee Add@tevel Szeeuccure Decumentation 


In writing about his experments on program ccmpre- 
hensicn, Shneiderman [Ref. 17] said "Instead or absorbing 
the pregram cn a character-by-character basis, programmers 
recognize «he functicn of groups of statements and then 
piece tocether these chunks to form ever larger chunks until 
*he entire DErodeate 2S  Ccomprehended. This experiment 
Suggests that the level documentation (chunks) of @ program 


Will help the understandability cf the progran. 
3. Standardizatic 


tandardizaticn contributes understandability cf a 


Program. Tc understand this, 1¢ 2S heipful to know the 
source cf the expert programming's capacity. The primary 
piece cf Ggnee ce behavioral evidence LOE this is 


Shneiderman's replication [{ Ref. 26] for programming cf Cha 


iD 


as 
and Simon's classic study on memory for chess’ position 
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{Ref. 27]. [Tne soth shese Studies, the expezts in a parti- 
cular domain could memorize informaticn from that dcmain 
(. 2. @ pregram or a chess position) far better than 
novices, provided that the information was appropriately 
structured. If the structure was made random (by shuffling 
“he statements of the pregram or rearranging the chess 
pieces), the advantage of the expert would be greatly 
reduced. That means that the expert has no better memory 
than the novice, but rather an elaborate knowledge structur: 
in terms of which ccrrespondingly structured items can be 
very efficiently enccded [Ref. 15}. 

If this result is extended to programming, ae 
suggests that the expert programmer gets his better know- 
ledge of programs frem visible program structure. As noted 
above, if the textual representation is not structured (€.g. 
random), the expert programmer will lose part of his capa- 
bility. Feceple understand something better when they can 
integrate it with what they already know. From this view, 
Standardization helps people tc understand other people's 
programs more guickly. The visual cues are important in 
order to unturden the program reader. The final objectives 
ef ccmputer program standards are to é€nsure consistency, 

¢ 


reduce program development and testing time, improve main- 


tainability of programs, and improve changeability of 
programs [Ref. 12]. Programming standards are not intended 
so stifle the imaginaticn of programmers. Experiments of 


Godfrey [Ref. 12] have shown that standards simply remcve 
the drudgery of coding and allow programmers to concentrate 
more cn the problem at hand. t Should be noted that the 
estabishment of standards is a costly process. It should be 
kept in mind that prcqramming standards are not a4 panacea 
soe eliminating all foorly written programs. Adherence to 
these standards will not automatically produce ‘'good' code 
[Ref. 12]. 
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{There are multiple levels of understanding a 
program. It is possitle to follow each line of code without 
understanding the overall program function. It may also be 
possible to understand the program function but not under- 
stand each of the steps. There is also 4 middle level of 
understanding concerning control structures, module design, 
and data structures [{Ref. 17]. Skimming for a top down view 
is tc suppress detail until the overall program is under- 
stood. Then the program is read salectively and understood 


in more detail. 
4. Exanple 


The following example wiil show how the reformat- 
ting, level structured documentation, and the standardiza- 
*i20n help the readability and understandability of a 
progran. 

The bDubbie-scrt algorithm wili be introduced for 
this example [Ref. 18]. The idea of the bubble scrt is as 
follows: "We go thrcugh a@ list comparing adjacent items and 
eeenanging thoss that are out of order. Dilcang Swen a 
compare-and-exchange fass, an item moves forward in the list 
Micit it ‘bumps up against a larger item." [Ref. 18}. A 
algorithm language [Ref. 18] and structured FORTRAN will be 


used for this example 


73 


mie ALGORITHM FOF BUEELE SORT ; 

Seadietes es BUDE LE 6 SOR 
Mev cers 2 (12 N) 
EPEAT 


NOSE xCHANGES <== eon 
ee ae C= = eal 10 N 1 
ae eae: > “LES? (ts 1 THEN 
Pree = LS 
Lise (r <-= rs (2 +1) 


“0 rit 
33) 


Peo ery) 5 — ENP 
Oe CHANGES s-- PALS 





UNFORMATTED FORTRAN FROGRAM FOR BUBBLE_SORT :; 
INTEGER Se 
LCGICAL NOEX 
READ (5,100) 
100 FORMAT (IS) 
eet OO} mio. 
5 CCNTINGE 
NCEXG = .TRUE. 
DO 777 T=1,N-1 
TE (.NOT. (LEST (I) . GT. LIST (I+1) ) Ouro eG 
Lee = & aE Aer: 
bist = List (i+ 1) 
Desh (iri) = LEME 
NOEXG = .FALSE. 
10 CCNTINUE 
777 CONTINUE 
SE een Att GO TO 5 
WR Bone oe ST. 
200 FORMAT (1X,1/7) 
S TOP 
END 
The follcewing shows some of the possible outputs of 
an extended pretty printer. Indentation is used to improve 


Teadakility. 


BeEeucture Of the prcgram both in 


ized programming language is used 


tandability. The reader selects 
that best supports his current 
needs. 
meveL ITA 3: 

INTEGER Dey ue )e I, 

LOGICAL NCEX 

READ (27400 N 

ReAD(>,100) LIST 

REGCEAT 

COMPOUND STATEMENT 

UNTIL NOT NOEXG 

WRITE (6,200) LIST 

STOP 

10Q PORMAT | ) 
200 FCRMAT (1X, 17) 

END 
ieveit LE : 

DECLARATION 

DECLARATION 

Sue Ries PALEMENT 
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Selective display of the levels of the centrol 


FORTRAN and 


tO support improved under- 


ina genes a.- 


the textual representation 


perceptual and ccgqnitivs 


Ng fone 





SIMPLE STATEMENT 
REPEAT 
COMPOUND STATEMENT 
ENDUNTIL 
5 Peres lA LHBENT 
SOP 
END 


This Shows, them ttese bevel of bubble sort 


Heré¢ only the repeat condition is represented, 


reader of the program can see simply the highest 


Beaiecure Ci the prcqram andcan understand the 


design of the program more easily. The reader 
select presentations that show additional levels 
completed program is displayed. 


mevel IITA ; 


i 
WR 
So 
00 FO 
00 FO 
EN 


mevGL ILE 


WAN wo 

rat rid 

rors 

win OF 

oe tttt 
CHdtd Orth 


rd Witt 
Zra Wiz 
OO so 
rm 50 
ttt 
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HeveL Lita : 


INTEGER LIST (100), I, N, TEMP 
OCT CAML 
READ 5 +199) N 
READ (5.100) LIST 
5 CCNTINUE 
NOEXG = - TRUE. 
DION Ia) ci aa 
IF met > LIST (I+1) THEN 
POUND STATEMENT 
END 
EG CONTINUE 
TP (NOT. NOEXG) GO TO 5 
WRITE (6,200) LIST 
STOP 
100 FORMAT (75) 
200 FORMAT eet) 


DECLARATION 
DECLARATION 
SIMPLE STALENENT 
Site LE STaPENENT 
REPRE An 
Sameer otAlLE MENT 
DCE AOR 
EE CONDITION THEN 
COMPOUND STATEMENT 
ENDIF 
ENDFOR 
ENDREPEAT 
Sees ola Lone NT 
SLOP 
END 


Fer most experienced vorogrammers who are familiar 
with top down design with stepwise refinement, the following 
representations are easier +o read and understand than the 
meeital programs. 


FINAL SOURCE PROGRAM : 

INTEGER LI Ist (100) -T, ,N,TEMP 
; LOGICAL NO 

READ 5-100) 

READ (5,100) LIST 

5 CONTIN OE 
NCEXG = . TRUE. 
DO 777 I=1,N-1 
IF(.NOT. (LIST (1) .GT-LIST(I+1)) GO TO 10 
TEMP = LIST (I) 





LIst (t+1) 
= TEMP 


Ww 

O 

Ht 

OH 

OM 

tH 

=~ 
fy ty ~ 
DD Mem ta 
= RIO Hi 
a Oe ~~ 
Ee AN un P< 
— f1] « & Hier 
ODMDHWO age” 


® 
@ 


FINAL STRUCTURE DOCUMENTATICN 


STATEMENT 


ENDIF 
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III. SOME AEPROACHES AND VARIOUS OBJECTS 
A. SCME APFROACHES 
There have been many attempts ie improve 


understandability and readability. The following are *ypical 


examples. 
1. Neater2 


Neater2 accepts a PL/I source program and cperates 
weet tC Ereduce a reformatted version. When in the LOGICAL 
node, heard cases mci e LOgicCad Structure of the scurce 
program in the indentation pattern of its output. A number 
of options are available to give the user full control over 


Beeewcucput format and to maximize its utility. [Ref. 19] 
2. Frettyprint 


It takes as input a Pascal program and reformats the 
Mmeegiam acccrding tc a standard set of pretty printing 
miss. The pretty printing rules are given i.s., £1xed. 
{Ref. 22] 


3. Eascal Program Formats 


ie 





Hesiaem 15 Mamotliexlplevpretty princer for Pascal 
Programs. It takes aS input a Ssyntacticaily-correct Pascal 
program and produces as output an aquivaient but refcrmatted 
Peacal Crogran. The resulting program consists of «the same 
sequence of Pascal symbols and comments, buc they are rear- 
ranged with respect tc line boundaries and columns for 


readability. [Ref. 20] 
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ther flexibility of Format is eccoup.asned Dy 
allowing the user tc supply various directives (options) 
which override the default values. Rather than being a rigid 
pretty printer which decides how a program is ‘to be 
formatted, the user has the ability to control how format- 
ting is done, [oc eCr yer n Omer o =“XeCucion buc also during 
execution through the use of pretty printer irectives 
embedded in the program. [{ Ref. 20} 


4. Centcur 


Home is sa | PECdram whose purpose is to gtaphically 
mebuetrate a pregram’s structure. It operates by kounding 
the scope of loops and conditionals by soiid (or anasarly 
solid) lines. When ccmpound statements are embedded in cther 
compound statements, one obtains, rather than confusion, a 
rather pleasant display reminiscent of the centour lines of 
a topcegraphical map. [Ref. 22] 


5. Synta 


It is a language independent pretty printer. It is 
divided into two phases: the grammer processing phase and 
the pregram processing phase. A language grammaz> for tha 
specific language must be provided. It is much 2asier and 
quicker tc write a qrammar for a language than to cede a 
new pretty printer for a specific language. I+ can work fer 
all structured programming languages, and with minor nodifi- 
cations, can work for other languages. I+ can handle such 
problems as comments and error recovery. [{Ref. 14] 


6. Qthers 


The recent availability cf low cost, he Gia g Wadase Vy 
computer printers allows additional opportunities to improve 
readability and understandability. Important characters or 


words can be represented with different fonts: for instance, 


ZZ 





the keywords can be represented by bold characters cr bs 
underlined to be recognized more easily than other words. 


This can improve the readability of prograa. 


B. VARICUS OBJECTIVES 


Althetgh the final objective of all approaches is to 
improve the readability and understandabilty of «he frogran, 
there are many seccndary objectives. The following are 
typical examples of them: 

Teaching structure: An automatic system that checks 
structure and indentations can help peginning students learn 
good prcgramming practice. A system that gives clear 
correcticns to mistakes can provide a student with quick 
feedback. Such a system helps a student to learn structured 
programming and to learn a set of programming standards. 

eeeandazdization ih a programming organization: Shes 
large software projects with many programmers, progran 
ctandardization is necessary to help in communication among 
programmers. 

Reformatting for maintenance: There are many programs 
that are very difficult to read. The maintenance precess 
can be helped if pregrams can be «transformed into a forn 
that is familiar tc the maintenance programmers. Tha 
scoping capability of an extended pretty printer as 
described above Gan else NS. p programmers understand 
programs they are correcting and modifying. 

mucectatic corrections: An extended pretty printer can 
check the indentation of programs, GOEESGe ~2ncentet ion 


errors, and give the user messages explaining the errors. 
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From the above observations, several common parts 


existing approaches can be found. First, most of the 


my tM 

I kh O 
in 
ctr 
(pb 


ace for a specific programming ianguage, nos 
programming language they would have to be written a 
The one exception is the syntex directed pretty printer; for 
each new language it requires a grammar for ¢éach 
language. Defining a correct grammar is not an easy task. 
Second, most of the systems try +0 make the pratty printer 
Meemtole, but the f£lexability is Timited to a few options 
and 1% is not easy tc extend the requests. Most ccnstructs 
Semene Eretty printers are fixed, but the constructs then- 
selves can be changed eé.g. extended or contracted. New 


structures for indentation can he generated. 
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A. DEFINITION 


Program families are defined by Parnas [{Ref. 13] as sets 
of pregrams whose common properties are so extensive that it 
is advantageous to study the common properties of the 
programs tetore analyzing individual members. Pregram fami- 
lies are analogous tec the hardwar2a families promulgated by 
several manufacturers. Although the? various models in a 
hardware family migh* not have a sSingie component in common, 
almost everyone reads the common ‘principles of oprations' 
manual before studying the special characteristics of a 
specific rodel [ Ref. 13]. 


Be LCESIGN METHOLCOLOGY 


Parnas [Ref. 13] shows how module specifications define 
a family. This is an important guide for selecting the 
design methcd. Members of a family of programs defined by a 


set of module svecifications can vary in three principal 


= 
nt 


a 


Se 


1. Implementation methods used within the nodules. 

Any ccmbination cf sets of programs which meet the 
module specifications is a member of the program family. 
Subfamilies may be defined either by dividing each cf the 
main modules into submodules in alternative ways, or by 
using the method of structured programming <«o describe a 


Bamtiy Of implementations for the nodule. 


Ze 





2. Variaticn in the external parameters. 
The module specificaticns can be written in terms of 
parameter so that a family of specifications tres 


u 
Programs may dicfer in the values of those parameters and 


still be considered to be members of the program family. 


3. Use cf subsets. 

In many situations one application will tequire only a 
subset of the functions frovided by a system. We may 
consider programs which consist of a subset of «he programs 
described by a set of module specifications to be members of 


a famiiy as well. 


As discussed above, there are many primary and secondary 
Spygectives for a pretty printer. One approach to these 
various demands would be to design a large program with many 
Seeesons. Such an aperroach has several drawbacks: first, che 
resulting program wceculd be large and nscessarily cemrlex, 
sscond, for each specific use of the program the unneeded 
ootions will most likely impose an unnecessary computational 
burden. The notion cf a program family offers an alterna- 
tive d2sign. A separate program will be written for 
d:fferent demands, hcewever, all these programs will share a 
common design and many modules will be common to several 
family members. 

The concept of program families provides one way of 
considering program structure more objectively. For any 
precise description cf a program family (either an inccn- 
plete refinement of a program or a set of specification or a 
combination of both) one may ask which programs have been 
excluded and which still remain [Reaf. 13}. The criteria of 
defining medules can be a way to select or distinguish scme 
design methcdologies [Ref. 3]. 
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C. FROGKAMMING LANGUAGE FOR OBJECT ORIENTED DESIGN 


A design nethodology alone is not sufficient te create 
computer solutions [ Ref. 3}. Some fsatures of a programming 
language can alse help in creating good software. Lawche 
following «able, P. Wegner has categorized some of the 


most popular languages into generations, along with scme of 


TABLE I 


Programming Language Generation Table 


ipenerat2on languages aoe 
AS FORTRAN I, ALGOL58 1954 = 1958 
2ND FCRTRAN II, ALGOLS50 1959 = 19617 
E@LEOL, LisP 
3RD PL/I ALGOL68, 1962 = 1970 
PASCAL 
GAP 1970 - 1980 


the language features they introduced: 
ACTA was developed a= the and of the language gqenera- 


tion gar, and sc has been influenced by contemporary soft- 


ware methodologies. Riese) fol Lowi ng figures show the 
topolegies cf each generation and ADA. ADA's topology is 
mee flat like those of the previous generaticns, Dut 


meeoucrc if multi~dimensional {Ref. 3]. 
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Figure 4,1 Topology for 1st and 2nd Generation. 
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Figure 4.2 Topology for 2st and 3nd Generation. 
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Figure 4.3 Topology of ADA. 


The following key features of ADA will suppert the 
tools for implementing the object oriented design 
meer. 23]. 


ieee eaCcogramming in the large. 

Mechanisms for encapsulation, separate compilation, and 
library management are necessary for the writing of portabie 
and maintainable programs of any size. 


meee ee XcCercticn handling. 

iaege Ppregrams are tarely correct. It is necessary to 
provide a means whereby a program can be construct 
layered and partiticned way so that the conseque 


€rrors in cre part can be contained. 


3. Data abstraction. 

Extra pertability and maintainability can be ocbtained 
1f the details cf the representation of data can be kept 
Separate frcem the specifications of the logical oprations on 
the data. 


a, 





4. Tasking. 

For many application it is important that the prcgran 
ke cenceived asa series of parailel activities rather 
than just as a single sequence of actions. Building appro- 
priate facilities into a language rather than adding then 
via calls to an opérating system gives better portability 


and reliability. 


pee Generic units. 

In many cases the logic of part a program is independent 
of the types of the values being manipulated. A mechanism 
is therefore necessary for the creation of related pieces of 
program froma single template. This is particularly useful 


for the creation of libraries. 
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A. PROBLEM AND SOLUTION 


As shewn above, most traditional approaches to pretty 
printers are for a specific programming language. A recent 
develcpment is the syntax directed pretty printer that can 
be used for different languages by providing a grammar of 
the language. The requirement to provide a language grammar 
represents anon-trivial task. Theres are many diiterent 
secondary objectives for a pretty Santer Or diner ent 
users. The functions of a traditional pretty printers are 
not enough to improve both the readability and understand- 
ability e.g. the program level construct documentation that 
traditicral approaches do not support is needed +0 help to 
understand a given program. ia SnOLe,, ners GES many 
programming languages and many purposes, but there is nota 
system that satisfies all those? requests and can be modified 
easily. 

In the previous section, th2 concept of a program fanily 
was discussed. The best way «to solve the various demands and 
Many programming languages is *o construct a vorogranm family 
BOr the extended pretty printer. hic’ Chekacteri,Stics: “Oc 
program family will permit easy changs, easy ¢xtensicn, and 
easy contraction. Each programming language will have a 
module for itself and data abstraction and sprocedural 
Beserecticn will be used to hide design decisions that will 
differ among the members of ‘the vrogram family. Data and 
PeececdUral abstracticn will also allow some modules to be 
used by all program family members. For example, the kLlank 
operations are a important data abstraction. These opraticns 
S@ameece USed for ali programming languages and cbhjectives. 
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B. GENERALIZED PROGRAMMING LANGUAGE CONSTRUCT 


Fer generalized indentation and level documentation, an 
general internal representation of program ZEuecure 2s 
required that is independent of any particular programming 
language. Let us call it a generalized formatter stucture. 
Since there are many frogramming language constructs in the 
many dirferent programming languages, it is too difficult to 
define a perfect universal programming languge formatter 
construct. So, we define here 2 generalized programming 
Manguage formatter ccnstruct that can cover cniy a limited 
number cf prcegramming languages - structured FORTRAN, PASCAL 
and scm2 cther structured programming languages. Yor simprl- 
icity, the detailed representation of a simple statement 
Willi te critted. 

The structure of the program will be shown by indenting 
Bxye constructs. MEcSt , Cmem Teleco l “Structure will he 
considered. Dijkstra argued that control flow should be 
limited tec three basic structures - linear sequences, struc- 
tured selection, and structured iteration. But many progran- 
femoeuse the following flve structures - if, case, while, 
until, de for. Also the block can be a element of the struc- 
mite. SeECOnd, most pregram units are divided into two parts: 
a declarative part and imperative part. This is alse impor- 
tant for the indentation. The Avpendix A describes in detail 


the generalized format structures. 
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C. ANALYSIS AND DESIGN 


1. Analysis 
The extended pretty printer has two basic functions. 
the first Su reformat the source program Sage 
indent,insert spaces and linefeeds between tokens and to 


decide where and how to break lines that are tco long te fit 
on the output medium. The second is to produce level struc- 
ture documertaticn of the source program. The basic require- 
ment of the total system is that it has to be easy to 
change, easy to extend, easy to contract, é€.g. it should be 
independent of the programming language and should be able 
Memrurtiil a variety cf purposes. 

Every structured programming language can be repre- 
sented as English is - character, word, stat2mert, compound 
statement (paragraph), unit program(a paper). What is of 
interest is the way to represent thes? component as lines. 
The relationship of these components and lines is very 


Bipottant fcr the extended pretty printer. Th 


D 


follewing 
table represents the relationship of line and statement. 
The other components have some relation with the state- 
ments. So, every comrfonent can be represented by lines. 

Each level is represented by the source precdqram 
Eem@uctures. The structures are represented by statements. 


SO, €ach statement can have a level deaqree. 
2. Design 


Az noted in the section on program families, ths 
mOoSt important aspect of this system design is to identify 
the objects. For the indentation, the line and statement ere 
basic elements. Blark is cthar important object. FOr tie 


construct representation, level has to be a object. 
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TABLES EE 
Relationship Table 


=e are ase 2 Sas ew SP FSS SPS SP SSF aes ses Se Sees SS See Se Se SP SP ee es 2S ee Se 


| LINE | STATEMENT | 
ocreas eas | 
rene ey | 
joke pee 
o Bevact? | 


_~aPe nr Se See SP SSP SP SPP BP ae ee Ss SF SP SP See eee SBP ee Se SP SP SP SP SP Se ee Se Se ee ee ee ee ee SS 


(*‘paxct™ means part or a statement) 


The heavily dependent parts should be encapsulated 
in a medule +o allow for easy change. The indentation 
policy can te changed variously, it needs to be manipulated 
independently. To manipulate the input programming languages 
independently, the program should bé a indepedent module. 
The program module needs some data structures - STACK, 
QUEUE -, Keywords tattle, and some statement oprations. fhe 
fiies - input source file and output file - and their format 
can be changed easily. So, th? input/output files manipula- 
tions need be separated from other modules. 

For convenience, «he modul2? will be divided intc two 
kinds. One is passive modules that are used by other modules 
but thact donot use other modules, for example, blank, 
level, stack, queue and line. Piesocher: Kind is active 
modules that use the other modules, for example, input, 
cutput, program and sc on. ADA will be used for the detailed 
design of the systen. The foliowing shows the detailed 
design. 
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(1). 
stack opraticns. 
for other mcdules 


Passive mcdulss 


Stack Module. This modulé provides scme 
And it provides the following procedures 
that use them [Ref. 24}. 


generic type ITEM is frivate 


package 
aye List 
procedure 
procedure 
precedure 
cb savereablone 
underflow 
type 
ioe, 
NODE 
head 


eau! 


private 


type 
type 


end 
ena STACK: 


(2). 
CUBUE oprations. 
for cther modules that use them [ Ref. 


STAC K 


is 
LS private; 
CREA oo emOwe O15 7) : 
PUSH (1: Lisi seen:: 
POP(E: inesout LIST); 
TOP(LS2EESL) xrceturn ITEM; 
JER C RET ION; 
NODE; 


is access NODE; 


ne Oo uc aot e eeae ty ty) ee 


is reccrd 
Feel eerie 


Sc eo es 


PeGer ds 


Queue Module. This module provides some 


And it provides the following rrocedures 


Dune 


generic type ITEM is private; 


package 
type LIST 
procedures 


Frocedurs 
== Insert 
procedures 
Delete 


underflow 


QUEUE 


is 


)4- 


S$ private; 
CREATE(L: o 


ENQUEUE(L; 
the item 


eee PET LON | 


aS 





private type NODE; 
type LIST is access NODE; 
type NODE is record 
head : ITEM: 
al, week S TS 
end record; 
end QUEUE; 


(3). Blank Modu 





This module provides all 


blank ocperations that insert, remove, GOun sand SO On £o0r 


other modules that need the blank operations. 


generic type INPUT is private; 
package ELANK is 
Bikes Go Nstamec. CHARACTER := ' *s5 
type NUM is NATURAL; 
EGG Cure inion (Ngte wan NUM: Ps out INPUT): 
Sinemstacte column of a Line | 
-- : =] Tasentmbes Of blanks =o De inserted 
Beocecure Davee bie ss tn NUM: ©: nea. INP OT) ; 
The start column of'3 
a 4 > The numter of blanks to ae deleted 
Bageceuce Symes sla ENPULT* ON: Out. NUM) ; 


emi necro f blanks Die one 
-- Eprom the start colunn 


mInceLoOn [SS BLANK(C: in CHAR); ceturn BOOLEAN; 
= Check the input character is blank 
a et blank Zecuen CRUE 
-- ise, return FALSE 
overflow : EXCEFTION; 
end BLANK; 
(4). Level Module. This module will provides 


the level operations for other modules chat need 
Operations are: 


package eve is 
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type NUM is NATURAL; 


procedure INCREASE(L:in out NUM); 
== Increase the level 
== L : input/cutput level number 


Pee oc tke DeGkmach(Lo20 Out NUM); 
Decrease the level 


peeeo ee ZERO(L:in out NUM); 
ake the level zero or starting Polac. 


GVorftlcw’s “EXCEETION; 
underflow : EXCEFTION; 
ema LEVEL: 


(5). Line Module This module manages the lines 


Oo a 


object. It provides a set of procedures available to cther 


modules that use the line. 


Generic type LINETYPE is private; 
package LINE is 
type LINEPOINT is private; 
type NUM is NATURAL; 
type CHAR is CHARACTER; 


rocedure GET LINE 

Bean, Out ee Le Out LINETYPE) ; 

-- Get a whole line into internal structure 
a Peer eDetOor a line 

-— feo cOncent Of a iline 


EFrocedure PUT LINE 

(220 Cue LINEPCINT: L: in LINETYPE) ; 

oa Put the a internal line into the li nezype 
= Peoweletor a Line. 

es EemecOrcent Of a ine 


procedures LINE LENGTH 

(een LENE POENT= N: out NUM); 
=< Sonn UES i hewn e length 
= P LDeror a ane 


procedure GET CHAR 

(2s am LENS POTNT; N; in NUM: out CHAR) ; 

a Get a character that is in given line and 
an csiton 

= Se eDeeOr “dew LVe 


Procedure PUT _CHAR 
(Cn eheN eeOmen Tse N; 3m ITEM: in CHAR) ; 


= Purmeomenc Vel chartacts® into the position 
= and the line given 
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—— Eve De fOrea Line .. 
-- N : Column of the line 


procedure FRONT INSERT 

(Ps in out PeNur ein: bs In LENE TY PE); 
== Insert line in front of the given 
== Line posicion 

a meee (Deeor a line 

-— Eee CoOntentc Of a line 


procedure REAR_INSERT 
(ee sn Cue LEINEPOINT: L: in LINETYPE); ; 
a Insert the line at rear of 
oe Ee Bee jane posit 210N 
== : fOmed Inc. 
= t : Bontent of a line 
underflow : EXCEETION; 
CV=-tlOw > EXCEPTION: 

mva te type NODE; 
type LINEPOINT is access NODE; 
type NODE is reccrd 


content oie NG YP: 


rien ie : LINEPOINT; 
Tear ol NES OLN: 
end record; 
end LINE; 
(6). Symbol Table Module. cman GUS) wae 
manage a symboi table. It is designed for general symbol 


manipulation. 


Generic type ITEMTYPE is private 

package SYMBOLIABLE is 
Meese constant == 200; == Size of symbol table 
iMEEMoIAZEs constant =: ~ 20; 
type ITEM is new STRING(1..ITEMSIZB) ; 
Frocedure PU ne lee hs ean TTEMTYDP®) ; 

Insert an item and the information 

a associated with it into SYMBOLTABLE 
Piicelen UNeTADLE(X:in LTEN) return BOOLEAN; 
-- Check To see if an item is in 
a foe SY IBOLTABLE 


finerten GET(Xsin ITEM) return ITEMTYPE;: 
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-- Retrieve the information ated 


associ 
-- with an item in the SYMBOLTABLE 


functicn FULL return BOOLEAN; 
-- eee aoe Whetner G5 Noc che SYMBOLTASBLE 


-- is fu 


so 


Frocedute GEEAR = Boa ble 
Reinitialize ({reseé 2 SYMBOLTABLE 


end SYMBCLTABLE; 


bt. Active ncdules 


(jee inpur Module. This module hides the input 


Beamat. it reads PRemOoLr= GaNdielenes £rom the input media 


ct 
oO 
i 
ib 


and calls rrocedures provided by tne line module to s 


the lines inside of the line object. 


with TEXT_IC; 
mech LINE: 
generic type LINEPOINT 


1 
(n 


Dives. 


package INPOT is 


procedure READFIILE 
Melee rs th ENPILELYPE; START =; out LINEPOINT) ; 
== Read the input eae earn store each line nto 
a imeemnal line struceure using LINE module 
a Pieter ne sppilt £ale chat have source vregranm 
-- SUN lone stesteng Line £D of internal 
=o Stcue un ¢ 
end INPUT 
Cys sOuzenur Modules. This module will hide the 


outfile media. Mie ct ieourt Oech e indented results, the 
construct form of the input program and the input using 


other modules - indent, line and so on. 


meh TEXT 10; 
with LINE; 


Sig 





with INDENT; 
generic type LINETYPE is private; 
package CUTPUT is 


type 


CUtreoe ree > TEXT LTOSFILE TYPE; 


avec CODE MLE TYPE TEXT [O.FELE TYPE; 
procedure PRINT CUTFILE 


(OUTFE 


ILF: out INFILETYPE; START : in LINEPOINT) ; 
Poatielelsmaenm=cd CUDPUS Into OUTFILE using 
indent and line modules 
OUTIFILE : The output f£il12 that has 

the indented source prcgram 
START Pee Mecmoraece los Licernal Structure 


procedure PRINT CODEFILE 


(COuUrPtIE: Cut, TNFILLET YPE 


end OUTPUT 


orien LINE POUNT): 
Point the code documentation using line and 
indent module ; 
CODEFILE : The output file thet has 

the cod documentation 
START eros tarre lh Of BPReerhnal structure 


(3). Statement Module. This module manages the 


statement object and also provide a set of procedures avai- 


lable to other modules that use the statement object by 


using line mcdule2 precedures. 


Meech LINE: 


generic 


tyre 


package 
type 
type 
type 
type 
type 


end 


INDENTPOINT is private; 
STATEMENT 2S 
NUM is NATORAL; 
CHAR is CHARACTER; 
PINDENTPOINT 25 access INDENTNODE; 
STATEPOINT is access NODE; 
NODE is reccerd 
content ome ti Pe. 
fee Ole SweSoLAce POINT: 
rear weS>LALEPOENT; 


BOCOrnG > 


4Q 





type STATETYPE is record 


from See Oo Lr TON : 
£C - POSTE LON ¢ 
information >: INDENTPOINT; 


end record; 

type PCSITION is record 
line Sele NEP OLN tT 
column so NU Me 

end Lecord ; 


PeOccaUze sGErestAle DE LIMITOR(D: in CHAR); 
-- Get statement delimitor 


function END_OF_STATE(D: CHAR) retuzsn BOOLEAN; 
— Check the Gnd of a statement 


procedure GET STATE | 
eee nee] cra hEOLNT; L: out STAT 
== Get a statement using LINE mo 


rrocedure PUT STATE 
(awe tc moat ©POINT?; Ls in STATETYPE) ; 
== Put a statement using LINE moduls 


procedure STATE LENGTH 
(ea nestALEPOLNT: N:; out NUM); 
2S Compute the length of a given statemert 


Frocedure RECOGNIZE STATEMENT 

(ee atmou con Al GEOINT; L: in LINEPOINT) ; 
== Recognize the statement from 

oS the internal line structure 


procedurs GET CHAR 

(2 in STATEPOINT; Nie a tie MS io 
== Get a character from the g 
a and column 


CHAR 
Tigesac 


(te 


u ) 
al atement 


© 
ve 


Frocedure PUT CHAR 

pee ota PEW ENT. Ns ian NUM: in cue 

== Put a character into the given statement 
= and column 


Peoccadure FRONT INSERT ; 

ae Cle ShATEEOINT; L: in STATETYPE) ; 
ms Insert the given statement into 

aS front of thé given statement ID 
procedure REAR INSERT : 

(eee ne Ole SEAL EPOINT; L: in STATETYPE) ; 
= Insert the giyen statement into 

== rear of the given statement ID 
mnaert low = EXCEPTION; 

overflow : EXCEFTION; 


end STATEMENT; 
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(44). Indent Module. This module wiil indent 
each line using the line module, statement modul¢ and rlank 
module. And the indentation policy can be decided here 2.g. 


the size cf each level, the treatment of planks, and so on. 


with BLANK; 
merhn STATEMENT ; 
meh LINE: 
generic type POLICYTYPE is private; 
mype CCNSTRUCTTY&SE is private; 
package INDENT is 
type INDENTPOINT is access INDENTNODE; 
type INDENTNODE is record 
level eee 
EQnScEGiey 2eCONSTRUCTTY P&E; 
end SOecerad ; 
(Bs in. STATEDOT NT; los out LENEDY PE) ; 
Indent a line i.e. znsert or delete blanks 
~— and make line break according to the source 


a regram syntex using_ che information about 
== eve lmaneG  CCHSesilc= zype and so on 


procedure GET _ PCLICY 

(P: in POLICYTY PE) ; . 

ea Get the indentation and objective opr 
a Ecr example, each level has 3 blan 

= and with indentation error messages 


grocéedure PUT. PCEICY 
fee cut POLICYT YEE) ; . . — 
== Put tne indentation and objective policies 


ELOC? edure GET INFORMATION 

teen STA TEPOLNTss L: out a LATETYPE 
os Get the information ror indent 
a and level dccumentation 


procedure PUT INFORMATION 

(eee Se ATEPOLNGs Ls in Seaver y 
-- Pitacie na crornas. cn tor ind 
-< and level dccumentation 


end INDENT; 
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(5). Pregram Module. This module will hides the 
program characteristics. It should be highly depender* on 
each programming language. It have two procedures - scanner 


and parser. 


with 
with 
with 
with 
with 
want fh 
wath 


EINE: 
STATEMENT 5 
ELANK; 

SY MECL TAD ILE: 
ESVEL; 
STACK: 
QUEUE; 


package FROGRAMPART is 


procedure SCANNER 

fseoomolce OtALEPOINT; L: out ITTENTYP=) ; 

ee Scan the scurc?e program and recognize 
—— each statement type for parser 


procedure PARSER; 
ae Reecogn:=ze the construct of the source 
a pregran 


end FROGHRAMFART; 


(6). Master Module. This module will centrol 


all abcve mcdules. 


wat h 
with 
meee fi 
with 


PROGRAMPART; 
mn) ENT > 
INPOT; 
CUTEUT; 


procedures : pM 
a= Cont e module for reformatting 


cture documentation 


Hi cte 
ca 
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Figure 5.1 Module Interface. 


The above figure exvplain the interfaces of 


each medule. The arrow dizection indicates using module. 


De. EXAMELE (FORTRAN) 


1. Standard Form 


There have been many attempts to standardize tke 
FORTRAN programming language. Here, the standard form will 
Bpomeeow the concept cf COMPATIBLE FORTRAN [{ Ref. IT]. ch 
following represent the rough standard forn. 


(iD 
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a. Basic Components 


It consists of four elements - character set, 


symbolic names, constants and array elements 
gr. Statements 


(ij se) statement Compenents. Statements are made 
up of such components as labels, keywords, symbolic names, 
constants and special characters. For Compatible FORTRAN, a 
stricter rule shculd be observed: (1). Statement iakels, 
keywords, symbolic names, integer constants should not have 
embedded blanks, except for key words GO TO, DOUBLE 
PRECISICN and BLOCK CATA, which may have blanks in the fosi- 
tions shcwn. (2). Where two alphabetic or numeric state- 
ment ccmponents ccme together with no other special 
characters retween them, a blank should be inserted. Example 


are: 
POU c= 1,10 DOm hoe =a 45 
REWINDJ Sheuld be written REWIND J 
REALAAA REAL AAA 
(3) Keywords, labels, symbolic names or constants shculd not 


ke split tetween two lines. 
(eee aN oD Ls wel. Pllvees eNO: CONnsidereda 4 sta s- 
ment but i¢ a tyve of line. It may not be labelled, executed 
or continued. Necte sspecially that END is not an executable 
statement with the same effect as SETURN in a subrpregram or 
STOP in *he main progran. 
(3). Format of State 


eae statement to cne initial 


eles. | Che Szandazd T2mzits 
Hhewand NO< “More than -<s 
Peiacinuation lines. 

(4). Order of Statements. The following table 
Show the erder of statements. By ‘header statement’! is meant 
a SUBROUTINE, FUNCTICN ot BLOCK DATA statememe. Horizontal 
lines within the table indicate that entities above the 


line must precede entities below the Line (if present). 
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PABLE LET 
Table of Statement Order 


| 
| | PEMENSTON Stacemencs | EXTERNAL 
| eee ee ee { Staecetenre 


Lines 








| 

| 

| 

| 

| | 
Comment{ DATA Statements | 
{ 

| 

| 

| 

| 


[eee ical lines indicate that the entities on either side of 


the line may be intermingled [{ Ref. 1]. 
Gemopecificat2on Stat =2nan cs 


Specification statements are non-executable 
statements which give information to the compiler. ie 
Pemsists Of TYPE (DOUBLE PRECISION, INTEGER, REAL, LOGICAL, 
ama CCMPLEX), DISENSICN, COMMCN, DATA and EQUIVALENCE. 


ieee leansrer Cl Control 


This consists of the GO TO statement, Computed 
GO TO statement, RETURN and STOP statements, Arithemetic IF 
statement, Legical IF statement, DO statement, and CONTINUE 


Statement. 
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Cpe Outeut 


Dice eonsises Of =he WRITE statement, READ 


Statement, ENDFILE statement, REWIND statement, EACKSPACE 
statement and FORMAT statement. 


f. Expressicn and Assignment 


This consists of the Arithemeti EXpESSSiOn, 


Logical expressicn, and Assignment statement. 
g. Frogram Units 


This censists of the Main progztan, Pune 207 


subprograms, Block Data, and Subroutine subprograms. 


The algorithm language [Ref. 18] is convenient for 
representing the generalized construct structure. Soy. (0 
represent the structured FORTRAN forn, it will be compared 

-th the algerithm language. Detail structured forms ars as 


melicws: 


ALGORITHM LANGUAGE RTRAN IV 


es ALGCEITHM 


ALGORITHM algorithm_name SHilomwacne Clnin column 1 
Statements 
END algcrithm_ name 


Ze IF_THEN Single statement 

iemecnodition THEN IP (condition) statemant 
statement 

END TIF 

Bie IF_THEN_multiple statements 

PmeecOondition THEN Weel Ue cond? <20n) GO TC 10 
statements statements 

END IF 10 CONTINU 


4. tiveness ct CONS ruct 
memecondition THEN ieee NGlameond=10n) GO TO 5 
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ih) 


tatements 1 


ELS & 
Statements 2 
END IF 
6 
5Ne Multiway selection : ELSE 
TF continue 1 THEN 
statements 1 
Beoet IF condition 2 THEN 
statements 10 
meoe LF condition 3 THEN 
statements_ 
BS 5 11 
statements 4 
END IF 
12 
meLSE is cptional) 
20 
Or. WHILE repetion 
WHILE ccndi*ion DO 5 
statements 
END WHILE 
6 
ie REPEAT repetiticn 
REPEAT 5 
statements 
Mirek condition 
Bia DO FOR repetiticn 
FOR I <- L TO M BY N DO 
Statements 
END FOR 10 
fen Can be omitted, in 
which casé4 BY 1 is a $sumed) 
a. Multiway selection _ CASE 
ee variable OF 
" Seatesnents_ | 
Ze cal 
; Seatements 2 
; statements 3 12 
ELSE 
statements 4 
ELSE CAS#£ 13 
feof 1s cptional) 20 
30 


Hoe FUNCTICN 


FUNCTION function_name(parm_1, 
statements 


ly 


eos tent 


GO T9 
S See LE 


tatement 2 
CONTINUE 


Gy 


ae, 


GO 
ce 


GO 
rE 


NGL weenat-ton 41) GO T0710 


Stecements _ 
Toe 20 


(.NOT. conam=oneayeGco TC 
Statements 2 

TO 

(NOt. cond: 209.3) 
Statements 3 

Lome 


GO 

CONTINUE 
Statements 4 

CONTINUE 


11 


Sow CG a2 


eNO Cconag, t26nN)) GO TC-5 
Statements 
GO TO 


CONTINUE 


CONTINUE 
Stacements 
iets Lae COnd 1 


zVOnjiGO- TCs 


in which case 


GO TO 20 
GO TO 20 
Variable 


we 


es { 


GO TO 
CONTIN 


St adic 
ao. 70 - 3/0 
CONTINUE 
Sec 


eee yr PAarM_n) 
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functicn_name_expressicn 
END function_name 


data eee FUNCTION funcztion_name(parm_1,...,parm_n) 
statements 
functior name = expression 
RETURN 
END 
11. FROCEDURE (SUBRCUTINE) 
PROCEDURE procedure name(parm_1,..-., parm_n) 
statements 
END procedure name 


SUSnOuIe se suproucse= Name (parm 1,..., Parm_n) 
S 


END 


This grammar represents the construct format of 
structured FORTRAN. It is a subset of the generalized format 
SeEueture. The control structure is limited to 5 structures 
mage, GaSe, While, until, and do. In the declaration part, 
the declarations will be statements. For more detail, the 


grammer figures (Appendix 8) can be referenced. 


See lime tatlens 


An ADA ccmplier was net available for this work. 
So, the FASCAL programming language was used tc iaplement 
the system. This loplementation is a little different from 
the design of the previous section because PASCAL does not 
Suppert all the ADA frogramming features. In order to simply 
the implementation, just a subset of the system was inple- 
[emeee ad, 1.6. the UNTIL conetruct is omitted. 

Also the implemented system does not cover all 
standard FORTRAN - i+ dces not include some keywords like 


PAUSE, REWIND and so on. Thereener Limstatitons cf this are 
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pice ic Mlcwa nds isnt l tnput programs should be syntaticaily 
correct tc get proper indentation and the level documenia- 
oO - 2. All input FORTRAN programs should be conform te 
the standard structured form mentioned in previous sections. 
3. The input lines should be short enough to indent without 
being extended onto the next line. That is the implemented 


system does not have the line break function. 


E. Internal Data Structure 


GQ) ease data St hueeure. The input line and 





output line are represented @S an array cfr Characters. 
Normally, programming langugages use 80 column per line. In 
actual programs, most lines do not use all of the columns; 
the mean cf programming line size is 34 [Ref. 2]. rene 
Maximum array is assigned for one line, space is wasted. So 
to save memcry and make the line flexible, a double linked 
data structure was used for the internal line structure. 
Also, a sentinel node will be used. It allows an easy check 
of an emrty input file. 

(2). Stakement Data Structures. As shown abeve, 
the relationship of line and statement is one to one or many 
SO one. Clearly, tne statement can be represented by the 
dine data structure. So, a line record will have information 
about statements. Comment statements will be ignored for 
Statement representation. 

(3). Construct Data Structure. Thé censtruce 
will have scme relaticnship with the statements e.g. one to 
cne fcr simple statements, one to many for others. The 
Statements can have the information of the construct, since 
every construct can be seperate into statements. For 
examtle, Bhoe DOM Censtruct consis of DO_COND statement, 
compound statement and END_DO statement. But here, the line 
also will have the construct information. It is sossible 
Since the relaticnshir of line and statement also ore to one 


and many to one. 
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c. The Program and Example Inout/Output 


Ft) 
vt 
=) 
iD 


Anyone interested in obtaining a copy o 


oJ 


ct 
(iD 
4 


Peogran should contact che author directly or the Corpu 
Science Department at <+he Naval Postgraduate Schcoel, 
Monterey, California. The example input output can be 
referenced in Appendix C. The example program does not have 
any méaning. It is written jus= to show the constructs of 


programs and the results of program execution. 


ot 





VI. CONCLUSION 

One of today's software problems is the very high ccst 
of develcfing and maintaining software. Much research has 
been devoted to solving this problen. One way to solve 
today's software crisis is to study software toois that can 
help peorle who serve in «he soitware area. 

This thesis designed and partially implemented a program 
family of extended pretty printers that can help to solve 
software problems by improving readability and understand- 
ama laty cf programs. 

The system will work for almost any structured progran- 
Ming language and for various secondary functions with only 
small changes 1n some modules. The design presented here is 
for a pregram family cf pretty printers. The program imple- 
mented here is one member in this family. Other members of 


the program family temain tc be implemented. 


De 
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Figure A.1 Program Structure. 
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Figure A.2 Declaration. 
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Figure A.3 Subprocedure. 
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Figure A.4& Main Procedure. 
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Figure A.5 Compound Statement. 
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Figure A.6 If Statement. 





t ENDCASE 





Figure A./ Case Statement. 


PME os a os sc ene ee ee eae ne eee ee ey ee 


i O— 7 WHILE_COND : COMPST ENDWHILE >) 


Figure A.8 While Statement. 





ee re 


O pL UNTIL COND 4 = CCHPST s{ ENDUNTIL a 


Figure A.9 Until Statement. 


| P , COMPST 
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Figure A.10 Do Statement. 
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| U BEGIN > COMPST p( ENDBEGIN ®@ 


Figure A.11 Block Statement. 
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Figure B.1 Program Structure. 
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Figure B.2 Subroutine. 


ee 





eae 


Figure B.3 Main. 
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Figure B.4 Compound Statement. 
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S Ss «IF_GO > COMPST 7 CONTINUE 0 


A{ GOTO CONT COMPST 


GOTO_IF COMPST 
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Figure B.5 If Statement. 
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Figure B.6 Case Statement. 
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Figure B.7 @hile Statement. 





CONTINUE COMPST 








Figure B.8 Until Statement. 
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Figure 8.9 Do Statement. 
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Figure B. 10 Case_Cond. 


Figure B.11 Go_TIf£. 
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Figure B.13 


State Chart 1 
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LABEL IF 





*CONTINUE' 





CONTINUE 


oe Ce ED a, ED oie TED age _ a a 
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L. 
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Figure B.14 StaterGnart 2. 
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Pigure B.15 State Chart 3. 
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| 

| 

| 
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| 

| 

| 

gD | 

| 

| 

"FUNCTION ' | 

| 

| 

O G | 

OTHERS _ 

Se | 

A | 

| 

TYPE 2 
| 

‘END’ 
| 
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| 
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a ee EE Se ee ee ee ee 


Figure B.16 
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Continuation of State Chart 3. 
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+69) RETURN ST 


SS ee SD ee SS et ee ei i OS ees ESS eee og SS eee ED ag = 


OTHERS 


a eS a I ei I Se a Se A i co OI I 


SIMPLE_ST 


7 a ce 


ee 


| 











Figure B.17 Continuation of State Chart 3. 
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APPENDIX C 
EXAMELE OF INEOT AND OUTPUT 


CCK KK Ke A I KK IK KK KK I KKK KK KK Ke OK 


C* * * MEK eK KK OK & 
Ce** TEST EROGRAM FOR THE AUTOMATIC ** #4 ex 4k Kx 
C*** INDENTATION PRCGRAM ssleckaclscladcacabbaedeates 
Cx * Sek tO a i ak 


CK KK He eK ee ee EK KK eK eK eK KO KK KK OK & 
c 


Cc 
KK He ee He ee ee Ee ee ee ee i A oe KK KK KK OK ok 


C MAIN FROGRAM 
CE A Ra RR RK a ai oi a RRR Re oe oo a a eo tak ok ok 


C 
Cate DECLARATION 


© 
HEP een, RoeeRS, RE (20) 
PNieeGrer tie, 13,0 D (20) 
F POGUWEAL Lier 2, £3 
a CCMECUND STATEMENT 
Cc SIMELE STATEMENT 
€ IF STATEMENT 
C CASE STATEMENT 
c WHILE STATEMNET 
C CO STATEMENT 
. 
Rea AR GTS poke ee 
100 eee 
ite ero OR . 
Roa 
1#5.0-6.7 
2+4.8 
CALL aT tea NE 
Peqe not. (T1.NE.1)) GO TO 1 
DOPS00 I = 1,20 
BE 
500 CONTINUE 
GC TO 444 
1 ECHR e oko GOs TO 72 
fed LE {.NCT. Lip) GO 11 
I11=I1+1 
GC TO 111 
11 CONTINUE 
GO TO 444 
Meaetis.te.3) GO 10 3 
I2=I2+1 
GO TO 444 
3 CCNTINGE 
T3=I3+1 
444 CCNTINOE 
R (11) =5.5 
Lf (rages 3 GOeTO 555 
emo Gies GO. LO 555 
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GO TO (5,6,7) 
5 CONTINUE 
BD (1) =5 9 
RD (2) =5.0 
GO TO 666 
6 CONTINUE 
RD (1) =6. 0 
RD (2) =6. 0 
GC TO 666 
7 CONTINUE 
DO 567 T=1,19 
RD (T) =FLOAT (I) 
567 CCNTINUE 
RD (20) 40.0 
555 CONTINUE 
R1=4.9 
T1=4%]2 
STOF 
END 


ANNAN 


CE HK ee he He ete He He eK OR KK KK KK KK RK KK 


C SUEROUTINE PROGRAM 
CARR He eR te HK RK KK OK KKK KK 


r SUBROUTINE SUB (RD, ID) 
- DECLARATION 


REAL R1,R2,R83, 8£(29) 
FUGEGER &1.n2,13,1D(20) 
: POCEC AMINE L2, L3 
i SIMELE STATEMENT 


READ(5,100) 1I1,12,13 
100 FORMAT (315 
L1 = . TRUE. 
; R1 = 1.5 
Ce** IF STATEMENT 
as CO STATEMENT 
IF(.NCT. (I1.NE.1)) GO TO 1 
DO 500 I = 1,20 
2 (1) =9 20 
1 CONTINUE 
FETURN 
END 


—_— ee ee eee ee ee eee ses es ee eee ee 
—_a ee eee eee eee ee ee eee ee eee 
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THEN 


ND 
Sie 


<a mo oe FY ie BIO 
OVO HHO 
Ht 4-4 04 Ay FU A, A 
<C <CecltttH riety 
MmMmmNnMNMNuNWNH 


FeyFey pr] 
He ae 
AYA, AAs 
Sst == 
Poh hd cobdby ee 
mM WN 


GENS - 


Ed Qo eg RRP 
RO mMMmNNNnNH 
OO K«Grtex 

Wy BG 
OAMUYUYU 
E42 5D Fr} fe] FY 
NEMNAAA 
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K 
OF PROGRAM 


RETURN 
ENC 





CK ke ko Ok Fo ok ok kkk tok x 


Cx * x ea gk a aca koko ok 
Gye ThSl PROGRAM FOR THE AUTCMNATIC *#* 42 4XEXERS 
C¥** INDENTATION PROGRAM ae TE Se Ae ee 
C#* x sea ek Ae keke ak ok ok 2k 


(CK A eR ME He eK eK Ke KK OK KK eK OK & 
c 


C 
CK Me ee HK ee ee eK KK i A eK KK eK KK Kk & 


c MAIN EROGRAM 
Ca eR a KK RK RO RK RK KK RK KK 


ce 
Cx** DECLARATION 


c 
Ree Rt, 2h 35 pk Dd2 0) 
MUPEGER 2,12, £3, 2£D(2,0) 
ROGUGAL LAagLZ, 13 
C 
ae COMEOUND STATEMENT 
Cc SIMPLE STATEMENT 
C IF STATEMENT 
c CASE STATEMENT 
C WHILE STATEMNET 
: DG) SME Iu oy a 
2 
POR MAR aes eee 5 
100 Ae 
L1= .TRUE. 
Ral =e 
1 #5.0-6.7 
Z 44.8 
Cll ivesUS (kL, 2D) 
Pei Nore tiene. 1)) GO TO 4 
DOr S00 2. = 1.20 
R(T) =0 -0 
500 CONTINUE 
GO TO 444 
1 PrieObe thee h.2)) GO TO 2 
111 Mets Nets Ll) GO TO. 71 
T1=I1+ 1 
GO TC 111 
11 CONTINUE 
GO TO 444 
2 Droste S)) GO LO 3 
T2=I 2+1 
GC TO 44y 
3 CONTINUE 
I3=I3+1 
Gag CON TINUE 
ES a2 
I (lee. 3 GOO 555 
Pei AaGt .3)e2GO TO: 555 
GO TO He 01) 
5 CONTINUE 
RD 3) 22:3 
RD{2)=5.0 
GO TO 666 
6 CONTINUE 
RD Peco 
RD (2) =6. 0 
GO TO 666 
7 CONTINUE 


Sg 





DO 567 [=1,19 
Wao oe 
0 / CONTINU 
RD (20) =40.0 
5155 CONTINU 
R1=4.9 
I1=4*T2 
Se 
END 


ANAND 


CE ee eo ee i ee oe KK eK KK 
UBROUTINE PROGRAM 


S 
CH ee eH RK KK KK KK 
F SUBROUTINE SUB (RD,ID) 
—_ DECLARATION 
REALTOR i7n2,k3, RD 
Mie Ger t1,i2, 03 
; LOGICAL L1,L2,13 
eee SINELE STATEMENT 


N 
3} Pies, LS 
= 
Tt 


20 
(k20) 


100 


€ 
7. (I1.NE.1)) GO TO 1 
Om 00ume—) 1,20 


R(T) =0 «0 
1 CONTINUE 


=_— eee ee eee eee eee ee ee ee ee ee ee 
—_ SS Se ee ee ee eee ee eee a eee 
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